home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1995 November / EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso / earcd / program / amos / amoslist.lzh / AMOSLIST / 000190_svcs1.digex.net!amos-request_ Thu Sep 14 12:48:53 1995 remote from shiva.msg < prev    next >
Internet Message Format  |  1995-10-02  |  4KB
  1. Received: from svcs1.digex.net (svcs1.digex.net [204.91.197.224]) by shiva.usa.net (8.6.10/8.6.12) with ESMTP id MAA20765 for <lee.kitchens@georgia.com>; Thu, 14 Sep 1995 12:48:52 -0600
  2. Reply-To: shiva!svcs1.digex.net!amos-request
  3. Received: (from daemon@localhost) by svcs1.digex.net (8.6.12/8.6.12) id NAA28452 for amos-out; Thu, 14 Sep 1995 13:02:11 -0400
  4. Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by svcs1.digex.net (8.6.12/8.6.12) with ESMTP id NAA28449 for <amos-list@svcs1.digex.net>; Thu, 14 Sep 1995 13:02:10 -0400
  5. Received: from mail.shlink.de (root@mail.shlink.de [194.64.6.2]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id NAA29547;  for <amos-list@access.digex.net> ; Thu, 14 Sep 1995 13:01:45 -0400
  6. Received: from alcatraz.alcatraz.org by mail.shlink.de with bsmtp
  7.     (Smail3.1.29.1 #1) id m0stGtR-000Sa7C; Thu, 14 Sep 95 18:12 MET DST
  8. To: shiva!access.digex.net!amos-list
  9. Message-Id: <wU0l9MD261aez4@p22.sixpack.pfalz.org>
  10. From: shiva!sixpack.pfalz.org!chris (Chris Hodges)
  11. Path: alcatraz.org!sixpack.pfalz.de!chris
  12. Subject: Re: sound compression
  13. Date: Sun, 10 Sep 1995 19:24:29 +0200
  14. X-Mailer: MicroDot 1.10 [REGISTERED 000261] via Connectline-CLMSortin 2.22
  15. References: <9509050636.AA38504@acs3.acs.ucalgary.ca>
  16. X-Gateway: ZCONNECT US shlink.shlink.de [UNIX/Connect v0.71]
  17. MIME-Version: 1.0
  18. Content-Type: text/plain; charset=ISO-8859-1
  19. Content-Transfer-Encoding: 8bit
  20. X-Z-VIA: 19950914083308W+1@alcatraz.org
  21. X-Z-VIA: 19950913102629W+1@sixpack.pfalz.de
  22. X-Z-TELEFON: V+49-89/8005856
  23. X-Z-POST: Kennedystrasse 8; D-82178 Puchheim; Germany
  24. Lines: 74
  25. Status: O
  26. X-Status: 
  27.  
  28. racurrie@acs.ucalgary.ca ("Robert Andrew Currie") wrote on 04.09.1995 some
  29. text under the subject Re: sound compression. I can't leave this
  30. uncommentated ;-)
  31.  
  32. RC>     Actually I finally got it to work. It seems that when the
  33. RC> Squash routine fails to compress data, it does not clean itself
  34. RC> up. The data that was unsuccessfully squashed is garbled. I
  35. RC> corrected for this in my conversion program by first making a
  36. RC> duplicate of the data and then attempting to squash it.
  37.  
  38. Aha! ;-) That's a known problem though ;-)
  39.  
  40. RC> The
  41. RC> routine now plays samples of any size up to a frequency of 15000
  42. RC> off of a harddrive with the sample segments being compressed. The
  43. RC> total memory usage is 10K.
  44.  
  45. Bigger chunky yield better compression rates ;)
  46.  
  47. RC> In total I can only get about 25%
  48. RC> compression which is not bad for large samples but pitiful for
  49. RC> smaller ones.
  50.  
  51. Depending on the sample, rates of about 50% can be achieved though ;-)
  52.  
  53. RC> What is delta-8 compression?
  54.  
  55. The next byte in the sequence is added to the old one, so only the
  56. differences to the values before are saved and that mostly gives better
  57. compression rates.
  58.  
  59. Delta-4 compression uses 4 bits to calculate the next byte. However, this
  60. only sounds acceptable on specific samples.
  61.  
  62. RC> Does AMCAF work on Creator?
  63.  
  64. No.
  65.  
  66. RC> I have theorized that for sound data, because of it's
  67. RC> sinusoidal nature, you might be able to get away with only
  68. RC> storing the differences between each sample byte.
  69.  
  70. That's the principle of delta (=difference) encoding ;-)
  71.  
  72. RC> The difference
  73. RC> should be far smaller than the entire sample range -128 to 127
  74. RC> and might be representable by only 3 or 4 bits which could
  75. RC> theoretically save you 50%-62%.
  76.  
  77. Correct. And this is still without compression. ;-)
  78.  
  79. RC> Has anyone thought of this or am I totally off base?
  80.  
  81. The Player 6, an optimized module replayer, already compresses it's sample
  82. by choice with delta-4 or delta-8 compression.
  83.  
  84. RC> I am assuming that each sample is represented
  85. RC> by a single byte which seems to correspond with the play time for
  86. RC> each sample.
  87.  
  88. Correct. One sample byte is a 8 bit signed integer from -128 to +127. The
  89. length of the sample in seconds is bytelength/frequency.
  90.  
  91. Bye, Chris Hodges <chris@sixpack.pfalz.org>      __   __
  92. A4000/40/5MB/400HD/CD; AMOS Extension-Coder __  ///  / / _____
  93. GCS d H s-:++ !g p? !au a18 w++ v? C+++     \\\///  / /_/ ___/ LOGOUT
  94. E---- N++ K- W------ -po+ t++@ !5 j-- R+ G?  \XX/   \__/ __/  FASCISM!
  95. tv- b+ D-- B? e+(++)* u++ h! f !r n+ !y+ AMIGA RULEZ!  \/
  96.  
  97. Belper (n.)
  98.   A knob of someone else's chewing gum which you unexpectedly find
  99.   your hand resting on under the passenger seat of your car or on
  100.   somebody's tight under their skirt.
  101. (from: "The Deeper Meaning of Liff")
  102.  
  103.